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@ Process for configuration management 

(g) In a process for ensuring compatibility of 
components in a system, system components 
are defined and relationships between two or 
more system components identified. From rela- 
tionships between components, Inter-relation- 
ships between these tdentifted relationships 
and possibly other components are detemnined. 
By validating integrity of either or both of the 
identified relationship and detemfiined inter- re- 
lationship and, based on a validating result, 
ensuring integrity of the kjentified relationship 
or detenmined inter-relatk)n8hip, compatibility 
of the components in the system is ensured. 
This process is particularly useful in eliminating 
incompatibilities between resident and mig- 
rattonal software in an automated computer 
system. 
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The invention relates to a process for ensuring compatibility between components of a computer process- 
ing system, particularly for ensuring the integrity of a system configuration, even if enhancements to one sys- 
tem component render it incompatible with another component 

Modern Industrial manLfacturing techniques make use of a known practice of manufacturing products 

5 made of many separate components, the components manufactured individually and later assembled into a 
finished article. This practice permits one component of the article to be modified without substantially altering 
the entire manufecturing process, and capitalizes on the efficiencies of compartmentalization. 

Using such component manufacturing practices, modifications made to a single component to enhance 
its performance or impleme:it innovative technology not previously available, facilitate continuing product de- 

10 vetopment without compromising production output of an existing product These component manufacturing 
practices permeate the Information and computer processing industries. 

Specifically, with the acvent of the computer age, such "component" designs proved essential in devel* 
oping commercial automated computing systems, which necessarily underwent hardware and software en- 
hancements to capitalize on new, previously undeveloped hardware and software technology. But for the abil- 

f 5 ity of the computer industry to apply these traditional component development practices for larger, complex 
systems, the rapid, widespread success of the nrKxlern computer system would likely not have occurred. 
Throughout the design, deve.opment and implementation of computer systems, maintenance of an operational, 
yet dynamic, system conf igLration is instrumental In successfully developing and maintaining a system of in- 
tegrated data processing components, e.g., central processors, printers, software applications and peripher- 

20 als. Thus, effective configuration management of these components and their operational relationships be- 
tween components becomes a vital requirement of the data processing industry. 

Early configuration management requirements were satisfied by crude, often en-or-prone methods. In 
these early systems, to mai jge. for example, untested software applications, system engineers generally es- 
tablish multiple, isolated an i separate environments (sometimes on separate disk storage units of a central 

25 processor), which are esse, tially complete, stand alone versions of an entire system application. Enhanced 
system applications, which e rten include necessary data "files", are migrated to one or nr>ore of these separate 
"environments", depending .n a development step next required. When all components are migrated to an en- 
vironment and sufficiently U ited, a new software "baseline" using a particular environment is established. The 
"baseline" usually is a resui of physically copying relevant data files. The baseline copy is then installed on 

30 Other existing or new compL sr systenns. Software versions and releases developed by this conventional proc- 
ess are often manually copi d by a system operator from tape to disk, or other storage media in file sets from 
a defined baseline. 

Unfortunately, because the design, implementation and testing phases of component development are 
typically of such long duratic i. by the time a software release is delivered to a production environment, system 
35 changes, occurring during co mponent development necessitate that subsequent changes be manually migrat- 
ed, independent of a baselir j release. As one might expect, as the number of changes increases, complexity 
of managing the release ins.jllatlon increases proportk>nally. What should be a simple environment migration 
(copying of data files) instead, is an involved, labor intensive process to ensure the integrity of a system con- 
figuration. , 

40 In conventional configu.atlon management, manual installation of modified components to a stabilized 
configuration demands spe.jialized user knowledge of the configuration. For example, if a software change, 
applied to a stabilized conf i juration corrects a problem affecting system operating parameters, the change 
would not take effect until th j processor had been "rebooted." In addition, a component modification, intended 
to correct one problem. ma> introduce other errors if improperly installed. Without knowledge of the environ- 

45 ment and system configuraton. an operator cannot ensure the integrity of a configuration. 

Conventional configure:. on management methods also maintain little historical data on an operating sys- 
tem configuration. Using su>:h methods, debugging errors is difficult The system does not maintain data es- 
tablishing which system cor. Iguration existed at point of system failure, often making error identification, iso- 
lation, recreation and resolL ion difficult or impossible. 

50 Information system prof : ssionals have made numerous attempts to improve and streamline software con- 
figuration management Ont: such effort includes a software tool capable of automated installation or removal 
of software components frOui any defined configuration. Although this automated system addresses many of 
the drawbacks in previous ccnf iguratbn management methods, it is limited to providing a set of written manual 
instructions and procedures ror one of three types of actions: 1 ) replace a resident file version with a new file 

55 version; 2) add new files to ii '.e system; and 3) entirely remove resident files from the system, without replacing 
them with now versions. (Se j Murtha. Amy J., "The Development of a Conf iguratk>n Control Tool." Electronic 
Systems Group. WestinghOv.se Electric Corporation (August 1991). This automated configuration manage- 
ment system, although facil..ating configuration management functionally only installs and de-installs soft- 
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ware files. The system is a file manager and is capable of identifying a file version and acting on a file version 
based on an SWC ("software change"). The system only maintains information about a specific file related to 
an SWC and provides no functional information about relationships of the files to other system components 
(e.g., hardware and operating software). 

Other efforts to address problenrts associated with conventional configuration management have focused 
on procedures and mechanisms for isolating software development environments. One such proposal, Soft- 
ware Configuration Environment ("SCE") maintenance. Involves establishing a set of individual environrnents, 
procedures and tools for a specific configuration. In this system, for each product release, one self-contained 
environment is created per phase and the different phases placed in a horizontal pipeline. Each environment 
is designed to be a self-contained set of files under control of a Source Code Control Systems (SCCS). See 
Banerjee. B.. "Implementation of a Software Configuration Environment." Switching Systems Division, Rock- 
well International Corporation (July 1990). 

In this system, each product release isdesigned to be composed of all entities in the corresponding pipeline 
and each new release is an extension of a previous release. Additionally, two. interconnected databases track 
user level change requests and problem reports and maintain records of resulting fixes in documents and code. 

This configuration management design merely maintains information about an environment dedicated to 
a specific version or release. It affords no assistance in identifying, validating and verifying Integrity of the 
system's configuration for non-determinative updates to components in a computer processing system. Al- 
though it contains information tracking requests for changes to system functions or to correct processing errors 
in the application logic, once changes are made in one of the nrtany individual environments, a complete new 
version of all entities in the horizontal pipeline is required. System operators cannot determine whether a new 
release will result in a product release incompatible with resident software or hardware until after the new re- 
lease has been dynamically tested by users in that environment Such a result exposes system developers to 
allegations of poor testing and development practices and often equates to significant computer downtime. 

Although the disclosed software conf iguratton environment eliminates some of the above-mentioned draw 
backs, it requires that system operators have a detailed knowledge of the functional application to organize 
and bundle the system packages. In addition, no method for ensuring that all system components are contained 
in a particular system conf iguratton is provided. 

Nor does the disclosed procedure address configuration management of non-determinative replacement, 
substitution, addition or removal of a component subset of a system configuration. It manages the configuration 
as a whole unit In non-determinative configuration management, as is true of conventional methods discussed 
above, if a change to a single system component requires installation or replacement of a complete copy of 
the resident software, system maintenance costs rise higher proportionately. 

The introductton of networtcs and decentralized processing environments adds a significant level of com- 
plexity to managing system configurations across distributed systems. In distributed architectures, system 
components are not confined to a single, isolated processing environment. Compatibility of system compo- 
nents and integrity of the environment require verifying compatibility and ensuring integrity across multiple 
environments running on various processing platforms. 

Wortc station technology, networtcs and client-server architectures introduce additional complexities in 
configuration management The cooperative nature of these distributed system architectures, having multiple 
remote locations with each location operating independently of another location and having separate system 
configurations, presented skilled artisans with complex, unresolved configuration management issues. 

In an attempt to address these new issues in configuration management, presented by the more contem- 
porary distributed computer processing systenns. Dean et al. developed a procedure for classifying areas sub- 
ject to and amenable to automated computer support. In their distributed system, configuration and structure 
of the distributed system modeled is described by defining structures, relations and components of a distrib- 
uted system. 

Conceptually, one approach to configuration management in the distributed process environment records 
and maintains infomfiation about a specific distributed configuration, without enforcing rigid configuration con- 
trol policies. Once the information is recorded, a consistency checker might examine the recorded information 
to highlight system irregularities. See Dean et al., "Cooperation and Configuration Within Distributed Systerrw 
Management," Computing Department, tancaster University (March 1992). 

Such a configuration management system fails to provide a method for maintaining a system environment 
subject to non-determinative changes in configuration. The disclosed method lacks a process for establishing 
predetermined dependencies prior to perfbnming any maintenance operation. In the disclosed system, conf ig- 
uratton and dependency information is merely recorded and subsequently examined. Before or after system 
maintenance, integrity of the configuration is not validated. 

Another attempt to resolve many of the problems inherent in contemporary heterogeneous platforms ad- 
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dressed disadvantages of multi-dimensional platfonms. See Perin. 'Configuration & Software Distribution in 
Maintenance Environments on Heterogeneous Platforms." Olivetti Information Services (August 1991). Perin 
describes a procedure for maintaining a system operating at various user locations in which the systems have 
quite different configurations. The procedure establishes a centralized system for identifying, resolving and 

5 implementing modifications to an existing application or hardware system. The discussed procedure utilizes 
conventional methods for managing a defined configuration. Separate established environments contain iso- 
lated operating environments for maintenance, testing and release of updated software vereions and releases. 

Each environment provides a specific set of support functions depending on an intended use for an en- 
vironment e.g.. 1) developing and testing. 2) testing only or 3) releasing. This procedure provides only for iden- 

10 tif ying. documenting and resolving errors in a production system. Perin does not discuss a procedure for main- 
taining the integrity of a system configuration to prevent errore introduced into a user environment during in- 
terface of a remote application with a control processor or upgrading/downgrading of a remolB location, inde- 
pendent of a shared location. 

In yet another configuration management alternative. Maymon discusses a systematic set of modeling 

IS tools used in conjunction with object-oriented nfK)deling techniques to identify and classify subscriber service 
objects managed by a management information base (MIB), operating under a network switching element 
(NSE). See Mayman. "An Information Model for Configuration Management of Switching Network Elements. 
Using OS! Tools," Bellcore (March 1991). The memory administration information model presented and dis- 
cussed in Maymon is a conceptual illustration of groupings of various data elements within the service MIB 

20 of the NSE. Mayman discusses a managed object class as an identified grouping of managed objects which 
share certain characteristics, each dass containing a number of attributes whose values define the service 
profile of ea^h managed object Composite managed objects resultf rom containment (aggregation) of superior 
and subord.nate managed object classes. 

The di&^osed tools and techniques define objects required to provide a customer a subscribed-fbr teie- 

25 communica Jon service. The system is limited to defining objects required to provide subscriber services. A 
disclosed operating system retrieves attribute and other relevant Infonmation about the managed objects. The 
disclosed s /stem is a roadmap for the objects managed by an operating system If an object managed by the 
operating s /stem changes, the informatk)n model also changes. The disclosed system is not capable of dy- 
namically verifying and ensuring that an object is or is not required to provide a specific service. 

30 An object of the present invention is to overcome the limitations of conventional methods. Accordingly, the 
present inv;jntion provides a process as defined in any one of the appended claims. 

The pre cess provides a universal process for ensuring the compatibility of components in a system, par- 
ticularly in i. /stems having many components which undergo non-determinative enhancement. In the inventive 
process, system components are first defined. After defining relevant system components, compatibility re- 

35 lationships between two or more system components are identified. From these identified compatibility rela- 
tionships, ir.ter-relationships between at least two compatibility relationships are determined. 

The CO npatibility relationships and inter-relationships may be assigned a dedicated control field, thus 
uniquely identifying each relationship and inter-relationship identified. Once the relatioriships and inter-rela- 
tionships ar 3 identified, validating integrity of the compatibility relationship and/or inter-relationship and. based 

40 on a validacing result, and maintaining integrity of the compatibility relationships and inter-retationships de- 
fined, ensu: e compatibility of system components in a system configuration. , 

Maintai:iing integrity of the compatibility may include taking one or more corrective actions to re-establish 
the integrity of the compatibility relationship or inter-relationship. 

In one tjmbodiment the process comprises the step of verifying integrity occurs before at least one oper- 

45 ation selectad from the group consisting of a partial or complete system installation, partial or complete system 
downgrade and partial or complete system upgrade. 

In another embodiment of the process at least one of the hardware, software applications and software 
languages are selected from more than one version. Each conresponding version may comprise at least one 
release. 

50 In yet a further embodiment the step of validating integrity occure before and after the at least one system 
installation, downgrade or upgrade. 

The present invention will be described further, by way of examples, with reference to the accompanying 
drawings, ih which:- 

Fig. 1 i:> a State Diagram in an embodiment of a configuration management system according to an env 
55 bodiment of the invention. 

Fig. 2 is a representative high-level process flow diagram for a full software upgrade function. 
Fig. 3 ij a schematic representation of the system architecture for a data processing system using an ex- 
emplary configuration management system. 
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Fig. 4 is a data flow diagram for the configuration management (CM) application, represented in Fig 2, 
Fig. 5 is a data flow diagram for the CM application for a partial software upgrade, 
Fig. 6 is a representative high-level process flow diagram for a language upgrade to the data processing 
system illustrated In Fig. 3. and 

Fig. 7 is a data flow diagram for the CM application for a language upgrade. 

The present invention addresses and eliminates the drawbacks of conventional configuration management 
methods for automated computing systems by defining components of the system subject to redesign, modi- 
fication, removal or replacement in a system to which non-determinative modifications occur. Representative 
system components may include hardware, software applications and user languages. Once the relevant com- 
ponents are defined, relationships between two or more computing system components are identified. An ex- 
emplary relationship might Include, but is not limited to, identified compatibility between a software application 
controlling printing of landscape document images and a particular printer model which provides landscape 
printing. In this example, the defined components are a 1) software application, and 2) printer. Afunctional 
relationship requires that the software application operate a specified landscape option. 

Identifying relationships necessarily results In relationships between two or nwre relationships or between 
a relationship and one or more components, hereinafter referred to as inter-relationships. Determining inter- 
relationships in the process according to the invention completes a configuration definition. The defined con- 
figuration is a basis for dynamically managing a system configuration. 

Managing the configuration includes validating integrity of a relationship or inter-relationship and based 
on a validating result, maintaining integrity of a defined configuration, having relationships and inter-relation- 
ships, and thus ensuring compatibility of system components in the configuration. Configuration maintenance 
may include, but is not limited to, notifying appropriate system operators of a relationship or inter-relationship 
inconsistency or taking corrective action to re-establish integrity of the configuration. A representative correc- 
tive action may include restoring a specified component to a previous condition or status, upon system detec- 
tion of an error in a pre-determlned relationship. 

Ensuring integrity of the defined system configuration may occur at various, pre-selected times. For ex- 
ample, verifying and maintaining defined configuration relationships and inter-relationships may occur when 
a new system component is installed. Adding a new fixed disk drive requiring enhanced-f unction operating soft- 
ware exposes a defined system configuration to a potential operating error if the relationship of the compo- 
nents are not verified. Thus, verifying and maintaining the integrity of the configuration is necessary after up- 
grading the disk drive. Subsequent verification and maintenance checkpoints may be required depending on 
the significance of the relationship to be validated and impact to the system if a relationship becomes corrupted 
between checkpoints. Other exemplary opportunities for verification of configuration integrity include 1) after 
an initial installation of a complete system, 2) installation of one or more components in a system, 3) a partial 
or complete downgrade of one or more system components (e.g., such as a hardware device or software ap- 
plicatton) to a previous version of a system component, or 4) a partial or complete upgrade of one or more sys- 
tem components to a later component verston. 

The process according to the invention is particularly useful when non-determinative changes occur to 
one or more components in the system, especially when the defined configuration includes components of 
different vereions, and even more so when the components defined to the conf iguratton are different releases. 

Many problems of conventional configuration management systems arise because insufficient information 
is maintained about a defined configuration during operatton. The present Invention overcomes this drawback 
of conventional methods, by optionally maintaining status information about the state of a defined configuration 
during specific periods, between pre-detenmined checkpoints. In a preferred method for recording such infor- 
mation, maintenance of configuration integrity includes writing data to a computer log. Such information may 
preferably be utilized in subsequent integrity validations to eliminate redundant validation processing. 

A prefen-ed embodiment of the inventive method is useful in eliminating incompatibilities between resident 
software on the computer system and migration software. This preferred method comprises defining resident 
software and migrational software components used in the computer system, klentifying compatibility rela- 
tionships between a first resident software and at least one of a second resWent software or migrational soft- 
ware and determining compatibility inter-relationships between at least one compatibility relationship and at 
least one resident software, migratwnal software or another compatibility relationship. Adedicated control field 
is assigned to each compatibility relattonship or compatibility inter-relationship and stored. Storing the dedi- 
cated control field permits subsequent automated retrieval of the control field for use in periodic integrity va- 
lidation. Then, prior to performing a computer operatton. e.g., a hardware reconfiguration, software upgrade 
or user language redefinition, the integrity of the computer system is valkjated by identifying system inconv 
patibilities. 

Finally, incompatibilities identified In the integrity validation are eliminated. Although alternatives exist for 
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identifying incompatibilities, a preferred method reads migrationaJ software and resident software identifica- 
tion data, verifies compatibility between resident software and migrattonal software by comparing current con- 
figuration data against the dedicated control field, and upon verification, updates current configuration data 
for the mlgrational software, now "new" resident software, in the computer system. Preferable computer op- 
5 erations are not limited to nrJgratlonal software installation, but may include a software upgrade or downgrade. 

Integrity validation in which Incompatibilities are identified may occur subsequent to performing a conv 
puter operation, and In response to an identified incompatibility, integrity of the original configuration may be 
maintained by restoring prior resident software to a previous, verified configuration. 

An embodiment of the present invention Is illustrated by the following non-limiting examples: 

10 

Example 1 

In an example of a configuration management system, a commercially available computerized document 
production facility has a variety of devices and applications, combined in multiple configurations over a range 
IS of version levels with a vaiiety of enabled features. In order to ensure proper combination of the hardware, 
software and other compooents of the document production system, the configuration management system 
coordinates proper combination of components. Including the version and release levels, against enabled sys- 
tem feature sets. 

In this example, the dccument production facility consists of components as represented in Fig. 3. The 
20 system core is comprised or a central processor unit (CPU) A. The central processor contains pemianent disk 
storage devices containing operational and other system parameter data, such as data stored in Programmable 
Read Only Memory Storage (PROMS) J and K. Other data, e g. boot-up data and operating system togs are 
stored on disk storage devices in the central processor. 

The document production system application, running on the processor invokes one of numerous appii- 
25 cation modules D stored o devices in the processor. A document scanner G scans external data from docu- 
ments. Scanned data rem. ins in disk storage managed by the processor. Printing devices E and F are conrv 
ponents of the document p oductlon facility and may be invoked by specific functions performed by the proc- 
essor or application moduli s. Designated application modules D, stored on central processor A provide a user 
Interface H for Interfacing > ;ith system users. 
30 A tape device B provic ^s for loading and backup of software applications, loading of font data, backup of 
system information from th ; processor or loading from a tape I. containing data or software L. to the processor 
or storage devices. 

In the configuration m nagement system for this document production facility, a configuration manage- 
ment state diagram is illus rated by Fig. 1. Prior to an initial installation of the document production system 

35 101. the system parametei files, e.g.; J and K. are built. 100. During Initial installation. 101, configuration of 
an electronic sub-system c xurs. Upon completion of an initial installation, software applications and default 
document productton facilt / languages are defined to the system. 102. From a language tape, using tape I 
(Fig. 3), primary and secor.dary languages are Initially loaded onto the central processor, 103. 

The installed documer : productton facility becomes the current configuration, having established hard- 

40 ware components, a particular software version and release for installed applications and designated user lan- 
guages, and is designatea as such, 104. Upon obtaining an initially configured system, system PROMS are 
updated and retain current conf iguratton Information for subsequent use in validating integrity of the system 
configuration, 106. 

During the operatronal ife cycle of the illustrated configuratton management system, modifications to ap- 
45 plicatk)n software, designa.ad user languages or system hardware necessarily result in system upgrades and 
downgrades. In the applica ion, CM (configuration management. 200) functions as a controlling module, per- 
forming one of various syst jm maintenance operations, e.g., upgrading or downgrading document production 
system components. Fig. 2. Upon upgrading or downgrading specific system components, the system PROMS 
are updated by the Real Tme Operating System (RTOS), 201, to reflect the modified current configuration 
so along with configuration 8t;:tus output to Dialog, 202. Subsequent to completk)n of an upgrade or downgrade 
operation, verification of th 3 environment integrity occurs. 

In the exemplary confi juration management system, the application CM, illustrated in greater functional 
detail in Figs. 4-7, dynamically nrmnages a system configuration throughout the various configuration states 
which may exist during the ife cycle of the document productton system. Each system component of a current 
55 configuration of the docun.int production facility is recorded on disk storage or PROMS. Relationships and 
inter-relationships requirea :o verify and maintain the integrity of the system are provided in data fields and/or 
functional application proc ssing. The data fields are encoded control fields identifying the compatibility of 
one system component (e j., software application) with another system component (e.g., printing device). 
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Through functional application processing, or manual validation, integrity of any possible configuration of the 
components is ensured. Table I illustrates representative relationship and Inter-relationship control data fields 
in the document production facility. 



TABLE I 
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15 



20 



25 



Date Type Designation 
Product Software Component 
Configuration ZZ 



Storage Location Description 



SW-Language 
Compatibility 



LL. FF 



CONFIG 



Textfite 



SW-Diag Utility 
Tape Compatibility 



BB 



CONFIG 



Produa Family, e g., 1 
E. 2 s Primer F, etc. 



Printer 



LL increments when language 
and software items have 
cnanges thai are not 
compatible. 

FF increments when there is a 
change to a language item 
which affects the function of 
the item. 

Compatibility number for 
Diagnostic Utility Tape 



30 



35 



40 



45 



50 
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10 



IS 



20 



25 



30 



35 



40 



45 



50 



Product SW 

Feature Level 



Language Feature 
Level 



'50 Characters" Textfile 



'50 Characters" Texlfile 



Language Component 
Configuration 2Z 



SW-Language 
Compatibility 



LL. FF 



Language Feature 
Level 



Diagnostic Utility Comoonent 
Configuration 22 
TABLE i (cont'd) 



SW-Oiag Utility 
Tape Compatibility 

Diagnostic Utility 
Tape Feature Level 



B8 



Controller Component 
Configuration Z2 



Primary-Language LL, FF 
Compatibility 



Secondary-Language LL, GG 
Compatibility 



CONFIG 



Texifile 



"50 Characters" Textfile 



CONFIG 



CONFIG 



" 50 Characters" Textfile 



Represents the SW Release Level. 
This is used for visual reference 
only. 

Represents the Language Release 
Level. This is used for visual 
reference only. 



Product Family, e g., 1 = Printer E. 
2 = Printer F, etc. 

LL increments when language 

and software items nave changes 

that are not compatible. 

FF increments when there is a 

change to a language item which 

affects the function of the item. 

Represents the Language Release 
Level. This is used for visual 
reference only. 



Product Family, e.g., I = Printer E, 
2 = Printer F, etc. 



Compatibility number for 
Diagnostic Utility Tape 

Represents the Diagnostic 

Utility Tape Release Level. This is 

used for visual reference only. 



PVRootPage Product Family, e.g., 1 = Printer £. 
2 = Printer F. etc. 

Textfile LL increments when language 

and software items have changes 
that are not compatible. 
FF increments when there is a 
change to a language item which 
affects the function of the item. 

Textfile LL increments when language 

and software items have changes 
that are not compatible. 
GG increments when there is a 
change to the Secondary language 
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item which affects the function of 
the item. 

Compatibility number for 
Diagnostic Utility Tape 



Represents the SW Release Level. 
This is used for visual reference 
only. 

Represents the Primary 
Language Release Level. 

Represents the Secondary 
Language Release Level. 

In Table I, control data fields are Identified for respective software, language, diagnostic and controller 
components in the document production facility. Configuration management control data fields for software 
applications include a configuration field ZZ, identifying compatibility of the software with a family of products. 
In this example, this configuration field specifies a code indicating whether a software application is "config- 
ured" to interface with a given hardware component (e.g.. a particular printer, scanner or user interface). 

Similarly, a concatenated SW-Language Compatibility control fields LL. FF contain encoded data indicat- 
ing whether either a nrwdif led designated user language or software application are incompatible. Specifically, 
data field LL. when incremented, identifies an incompatibility between a modified software item and system 
language. FF. like LL. when Incremented, indicates that a modification to a designated user language is no 
longer compatible with a software component in the cun-ent configuration. 

Athird control field. SW-Diag Utility Tape Compatibility identifies a specific utility tape which is compatible 
with the specific nrKxiified software. The remaining two data fields store text information used for visual ref- 
erence to a particular software tape. 

Control data fields exist for other system components as illustrated in Table I. However, the number and 
types of fields may vary, depending upon the number of relationships, inter-relationships and infonmation re- 
quired about these relationships or inter-relationships to ensure and maintain integrity of a current configura- 
tion. 

Once the control fields (relationships) are Identified to the system and a current configuration of the docu- 
ment production system established, ongoing maintenance of any potential system configuration occurs at pre- 
determined processing points. 

Fig. 4 illustrates a configuration management data flow for a full software application upgrade to the docu- 
ment production system. An upgrade may enhance current application functionality or correct deficiencies un- 
detected in a prior software version. The CM application governs data flow through the system. From the tapes 
SWLabel. PrimaryLabel, PrimaryLangVersion and HWConfiguration. control data fields ZZ, LL and FF and 
other relevant configuration textual data are retrieved from the text files . This data will be used to subsequently 
verify the integrity and ensure compatibility of the "upgraded" current system configuration. Hardware config- 
uration infonmation. read from system data stores, is provided to the CM application for interpretation. 

Upon analysis of the control data retrieved from application files or read from system data stores, the CM 
application Instructs installFlte to load the software files from tape I to internal fixed storage (disk) on the CPU 
A. Simultaneously, installFile updates permanent system files with cun-ent configuration control data. A full 
software upgrade is completed and the integrity of the system is ensured. Upon successful completion of the 
full software upgrade, the system software label is updated (yia SWLabels) and status Infonmation. reporting 
on the integrity of the upgraded current configuration, Is provided to users through the system application Di- 
alog (Fig. 4). 

Example 2 

This example utilizes the functionality of a configuration n^anagement system in Example 1 for a partial 
software upgrade, i.e., only preselected, modified software files are loaded onto the system. Fig. 5 represents 
a data flow diagram for configuration management of a system partial software upgrade. The sequential data 
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flow of this functional operation con-esponds to the data flow for a full software upgrade, with one exception. 
The process distinctions beiween a partial and full upgrade reside in the final configuration management proc- 
essing. In a partial software upgrade, SWLabels, identifying the software resident in the cun'ent configuration, 
is not read by CM for display to Dialog. No change to the system configuration requiring user notification occurs. 

5 

Example 3 

Figs. 6 and 7 illustrate a high-level process flow diagram and a data flow diagram for a language upgrade 
to the document production facility described in Example 1. Fig. 6 shows configuration data (2Z. BB, LL, FF 

10 and text, identifying configuration relationships and inter-relationships) from PROMS, tape configuration and 
tape and disk application and data files Text (Tape Text and Disk Text). This data is processed by the Real 
Time Operating System (RTOS), 201. which in turn sends data to the CM application, 200. Upon completion 
of a language upgrade. CM delivers diagnostic information to Dialog and configuration data back to RTOS for 
system update (full language upgrade). 

15 Fig. 7 is a detailed data flow diagram for CM application when performing a language upgrade to the docu- 
ment production system. As in Examples 1 and 2, control field data for the upgraded language is retrieved from 
LanguageLabel and LanguageVersion. Current component configuration control data ZZ is read from system 
data stores in HW Conf iguratton from PV Root Page, and Primary and Secondary version from CPU disk stor- 
age. PV Root Page and current configuration language label and version control data (Language Label. LL 

20 and FF) are read from system storage data files on CPU A. This information is then used to determine subse- 
quent upgrade processing. Upon confirmatton that current configuration data and upgrade label and version 
data are consistent and the configuration integrity validated. installFite transfers language files from tape to 
system disk storage, and updates current system version and label configuration data files on CPU A. Current 
configuration control version and label data is transferred to CM which provides diagnostic information to Di- 

25 alog for interactive user viewing. 



Claims 

30 1. A process for managing a configuratbn and ensuring compatibility of components in a computing system, 
including 

defining comporients of the system; 

identifying relationships between at least two computing system components; 
determining inter-relationships between at least two relationships; 
35 validating Integrity of at least one of the relationship and inter-relationship; 

obtaining a valicating result; and 

based on the validating result, maintaining integrity of the relationship and inter-relationship, thus 
ensuring compatibility of the system components. 

40 2. A process according to daim 1 , wherein the validating result indicates that the integrity of the at least one 
relationship or inter-relationship no longer exists and the step of maintaining integrity comprises a step 
of taking corrective action to re-establish a lost integrity. 

3. A process according to daim 1 or daim 2. wherein the system components comprise at least one of hard- 
^ ware, software applicaibns and software languages. 

4. A process according to daim 1 or daim 2, wherein the step of maintaining integrity comprises a step of 
writing data to a computer log for subsequent use in the step of validating integrity. 

5. A process for eliminating incompatibilities between resident software in an automated computer system 
^ and migrational software, comprising the steps of: 

defining resident software and migrational software used in the auton^ted computer system; 
identifying compatibility relationships between a first resident software and at least one of a sec- 
ond resident software and the migrational software; 

detenmining compatibility inter-r8latk)nships between at least one first compatibility relationship 
^ and a previously defined second compatibility relationship or a component; 

assigning a dedicated control field to each compatibility inter-relationship or compatibility inter- re- 
lationship; 
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Storing said dedicated control field for subsequent retrieval; 

prior to performing a computer operation, validating integrity of the computer system by identifying 
incompatibilities; and 

subsequent to validating integrity and performing a computer operation, ensuring integrity of the 
computer system by eliminating incompatibilities. 

A process according to daim 5. wherein the step of validating integrity comprises the steps of: 
reading migrational software and resident software Identification data; and 
verifying compatibility between resident software and migrational software by comparing identi- 
fication data against the corresponding dedicated control field. 

A process according to daim 5 or daim 6, wherein the computer operation is at least one of an installation 
of migrational software or an upgrade or downgrade to resident software. 

A process according to any one of dainns 5 to 7, further comprising the step of revalidating integrity of 
the computer system subsequent to performing a computer operation. 

A process according to any one of daims 5 to 8. further comprising the step of restoring the resident soft- 
ware on the automated computer system to a pre-operation configuration in response to an identified in- 
compatibility. 

A process for managing a configuration and ensuring compatibility of components in a computing system, 
comprising the steps of: 

identifying components of he system; 

identifying an initial configuration of the components by identifying at least a first relationship be- 
tween at least a first relationship between at least a first pairof said components and a second relationship 
between at least a second pair of said components; 

identifying at least one inter-relationship between said at least first relationship and said second 
relationship; 

periodically sampling a current configuration of said components; 

comparing said current configuration to said initial configuration to obtain a validity result; 

indicating one of a compatibility state and an incompatibility state based on said validating result; 

and 

taking corrective action when said indicating step indicates said incompatibility state and recording 
as said initial configuration said current configuration when said indicating step indicates said compati- 
bility state. 

A process for eliminating incompatibilities between resident software and migrational software in an au- 
tomated computer system, comprising the steps of: 

identifying resident software and migrational software used in the automated computer system; 

Identifying compatibility relationships between a first resident software and at least one of a sec- 
ond resident software and the migrational software; 

Identifying compatibility inter-relationships between at least one of said compatibility relationships 
and at least one of another of said compatibility relationships, a previously defined second compatibility 
relationship and a component; 

assigning a dedicated control field at at least one of each of said compatibility relationships and 
said compatibility Inter-relationships; 

storing each of said dedicated control fields for subsequent retrieval; 

periodically sampling cun-ent configurations of said relationships and inter-relationships; 

comparing said current configurations to said dedicated control fields; and 

taking corrective action when said comparing step indicates inconsistencies in compatibility and 
recording said dedicated contrd fields as said current configurations when said comparing step Indicates 
consistency in compatibility. 
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